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DETAILED ACTION 

Claim Rejections - 35 USC §103 

The following is a quotation of 35 U.S. C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

Claims 1, 2, and 4-65 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Spencer (U.S. 6,633,907) in view of Kelly (U.S. 2001/0056397). 

As per claim 1 , Spencer teaches a method for automated provisioning of computer 
networks, comprising the steps of: receiving at least one command to be executed on a network 
device (column 8, lines 24-57; column 9, lines 16-62); reading parameters related to said 
network device (column 8, lines 24-57; column 9, lines 16-62); determining whether the at least 
one command can be properly executed on said network device based on the parameters read 
(column 9, lines 16-62); and executing the at least one command on said network device only if 
it is determined that the at least one command can be properly executed (column 9, lines 16-62). 
Though Spencer teaches the reading of network parameters from a source, it is not specifically 
taught that the network parameters are read from a network database. Kelly teaches the reading 
of parameters from a network database (paragraph 0029). It would have been obvious to one of 
ordinary skill in the art at the time of the invention to include the use of a database from which 
parameters may be read, as taught by Kelly in the system of Spencer, as the use of a database 
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holding parameters is well known in the art of computer provisioning. If parameters are read 
from anywhere, there must exist a source, and it is very common in the art that this source be a 
database. Therefore, such a specific inclusion constitutes a well known design choice. Also, 
both inventions are from the same field of endeavor, namely the retrieval of data through a 
network. 

As per claim 2, Spencer-Kelly teaches the method of claim 1, wherein the at least one 
command is executed by an agent on said network device (Spencer: column 9, lines 16-62). 

As per claim 4, Spencer-Kelly teaches the method of claim 1 , further comprising the 
steps of: receiving a message that at least one command is to be executed from a secure 
provisioning network (Spencer: column 9, lines 16-62). Spencer-Kelly does not specifically 
teach the requesting of verification of the validity of the message. It would have been obvious to 
one of ordinary skill in the art at the time of the invention to include a method to request the 
validity of a command message. When commands are given, it must be certain that these 
commands are coming from the correct place, so as to prevent fraudulent rollbacks or 
configurations. Including a specific verification scheme would prevent against undue rollbacks 
and faulty configurations. Including a security measure constitutes a design choice and therefore 
does not constitute a patentable distinction. 

As per claim 5, Spencer-Kelly teaches the method of claim 4, wherein the step of 
verifying is accomplished by way of communicating with a communication gateway of the 
secure provisioning network (Spencer: figure 2; column 3, lines 52-54; where the 
communication gateway is read as the master object, which, in the figure is in contact with the 
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SCOs, user pages, and data stores. It is the point of contact, thus constituting a communication 
gateway.). 

As per claim 6, Spencer-Kelly teaches the method of claim 1, wherein the step of 
determining is based on reading software packaging parameters (Spencer: figures 2, 3; column 
2, lines 7-12; where the figures show different types of services, or packages, being provisioned, 
and the SCOs provisioning their own online service implies a determining process by package, 
where certain parameters would lead to certain services being provisioned). 

As per claim 7, Spencer-Kelly teaches the method of claim 6, wherein the software 
packaging parameters comprise compatibility requirements (Spencer: column 4, lines 10-21; 
where the existence of distinct software packages to be provisioned implies the existence of 
compatibility requirements. Compatible SCOs must be used to provision the appropriate 
service). 

As per claim 8, Spencer-Kelly teaches the method of claim 6, wherein the software 
packaging parameters comprise software roles (Spencer: column 4, lines 10-21; where the 
different services constitute different software roles.). 

As per claim 9, Spencer-Kelly teaches the method of claim 7, wherein the compatibility 
requirements comprise software roles' compatibility requirements (Spencer: column 4, lines 10- 
21; where the different services, or software roles, inherently possess compatibility requirements, 
as evidenced by the use of different SCOs for different services.). 

As per claim 10, Spencer-Kelly teaches the method of claim 6, but does not specifically 
teach the use of operating system parameters as software packaging parameters. It would have 
been obvious to one of ordinary skill in the art to include operating system parameters as 
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packaging parameters at the time of the invention, as it is well known in the art. The motivation 
for doing so is to allow for another type of parameter to be used to further classify the 
provisioning process. 

As per claim 11, Spencer-Kelly teaches the method of claim 7, but does not specifically 
teach the use of operating system compatibility requirements as compatibility requirements. It 
would have been obvious to one of ordinary skill in the art to include OS compatibility 
requirements as compatibility requirements, as it is well known in the art. The motivation for 
doing so is to prevent the loading of incompatible operating systems, which would lead to 
inefficiency in the provisioning process. 

As per claim 12, Spencer-Kelly teaches the method of claim 6, wherein the software 
packaging parameters comprise parameters regarding specific customer account requirements 
(Spencer: column 4, lines 10-11). 

As per claim 13, Spencer-Kelly teaches the method of claim 7, wherein the compatibility 
requirements comprise requirements regarding specific customer account compatibility (Spencer: 
column 4, lines 12-16; column 3, lines 48-50; where the user chooses which services are needed, 
and the master object determines whether the user is allowed access, thus constituting 
compatibility.). 

As per claim 14, Spencer-Kelly teaches the method of claim 8, wherein the software roles 
comprise customer account software roles (Spencer: column 4, lines 10-21; where the customer 
account governs which roles are provisioned). 

As per claim 15, Spencer-Kelly teaches the method of claim 9, wherein the software roles 
compatibility requirements comprise account software roles compatibility requirements 



Application/Control Number: 09/838,135 Page 6 

Art Unit: 2145 

(Spencer: column 4, lines 10-21; where the customer chooses which software roles are required 
to be provisioned). 

As per claim 16, Spencer-Kelly teaches the method of claim 6, but does not specifically 
teach the use of device parameters as software packaging parameters. It would have been 
obvious to one of ordinary skill in the art at the time of the invention to include this limitation, as 
it is well known in the art. The motivation for doing so is to prevent incompatible devices from 
being loaded, which would lead to inefficiencies in the provisioning process. 

As per claim 17, Spencer-Kelly teaches the method of claim 16 on the basis of 
obviousness, but does not specifically teach the use of device interface parameters as device 
parameters. It would have been obvious to one of ordinary skill in the art at the time of the 
invention to include this limitation, as it is well known in the art. The motivation for doing so is 
to allow for the compatibility of device interfaces to be a determining factor in the provisioning 
process, allowing for further efficiency. 

As per claim 18, Spencer-Kelly teaches the method of claim 17 on the basis of 
obviousness, but does not specifically teach the use of internet protocol address parameters as 
device interface parameters. It would have been obvious to one of ordinary skill in the art at the 
time of the invention to include this limitation, as it is well known in the art. The motivation for 
doing so is to allow certain IP addresses to access specific provisioning services which are better 
suited to provision a certain IP address requesting a specific type of service. This allows for 
further efficiency in the provisioning process. 

As per claim 19, Spencer-Kelly teaches the method of claim 17 on the basis of 
obviousness but does not specifically teach the use of interface type parameters as interface 
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parameters. It would have been obvious to one of ordinary skill in the art to include this 
limitation, as it is well known in the art. The motivation for doing so is to prevent incompatible 
interface types from being used in the provisioning process. Interface types should be as 
efficient as possible, allowing for specific interfaces to correspond to specific services being 
provided. This allows for further efficiency in the provisioning process. 

As per claim 20, Spencer-Kelly teaches the method of claim 16 on the basis of 
obviousness but does not specifically teach the use of interface components parameters as device 
parameters. It would have been obvious to one of ordinary skill in the art to include this 
limitation, as it is well known in the art. The motivation for doing so is to prevent the use of 
incompatible or disallowed interface components in the provisioning process. For the invention 
to function, compatible interface components must be used, or it will fail, so there must be a 
parameter in which only compatible interface components can be used. 

As per claim 21, Spencer-Kelly teaches the method of claim 16 on the basis of 
obviousness but does not specifically teach the use of memory components parameters as device 
parameters. It would have been obvious to one of ordinary skill in the art to include this 
limitation, as it is well known. The motivation for doing so is to allow only those devices that 
meet certain memory requirements to be used in the provisioning process, adding to the 
invention's efficiency. 

As per claim 22, Spencer-Kelly teaches the method of claim 16 on the basis of 
obviousness but does not specifically teach the use of storage components parameters as device 
parameters. It would have been obvious to one of ordinary skill in the art to include this 
limitation, as it is well known. The motivation for doing so is to allow only those devices that 
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meet certain storage type requirements to be used in the provisioning process, adding to the 
invention's efficiency. 

As per claim 23, Spencer-Kelly teaches the method of claim 16 on the basis of 
obviousness, but does not specifically teach the use of central processing unit parameters as 
device parameters. It would have been obvious to one of ordinary skill in the art to include this 
limitation, as it is well known. The motivation for doing so is to allow only CPUs that meet 
certain requirements to be used in the provisioning process, adding to the invention's efficiency. 

As per claim 24, Spencer-Kelly teaches the method of claim 7, but does not specifically 
teach the use of device compatibility requirements as compatibility requirements. It would have 
been obvious to one of ordinary skill in the art to include this limitation, as it is well known. The 
motivation for doing so is to allow only devices that are compatible with the system to be used, 
since the invention will fail if incompatible devices are used. 

As per claims 25-31, Spencer-Kelly teaches the method of claim 24 on the basis of 
obviousness. These claims are rejected on the same bases as claims 17-23 respectively, as 
compatibility requirements are specificities of parameters used in the invention and obvious in 
the same manner. 

As per claim 32, Spencer-Kelly teaches the method of claim 8, but does not specifically 
teach the use of device roles compatibility requirements as software roles compatibility 
requirements. It would have been obvious to one of ordinary skill in the art to include this 
limitation. The motivation for doing so is the necessity of using devices compatible with 
software roles, which, in turn, must also be compatible with the system to be able to provide 
provisioning services. The invention would fail if these requirements were not met. 
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As per claim 33, Spencer-Kelly teaches the method of claim 9, but does not specifically 
teach the use of device roles as software roles. It would have been obvious to one of ordinary 
skill in the art to include this limitation, since software roles necessitate the use of devices. The 
inclusion of device roles as software roles allows for a better system of grouping by certain 
characteristics, than if device roles were not included as a classification of software roles. The 
inclusion of this limitation makes for easier grouping of software roles, which can then be used 
as parameters. 

As per claim 34, Spencer-Kelly teaches the method of claim 6, but does not specifically 
teach the use of application packaging parameters as software packaging parameters. It would 
have been obvious to one of ordinary skill in the art to include this limitation, as it is well known 
in the art. Application packaging parameters are merely specificities of software packaging 
parameters. Forjudging whether a command can be executed by software packaging 
parameters, application packaging parameters must be known, since they are a key part of 
software parameters. 

As per claim 35, Spencer-Kelly teaches the method of claim 7, but does not specifically 
teach the use of application compatibility requirements as compatibility requirements. It would 
have been obvious to one of ordinary skill in the art to include this limitation, as it is well known. 
It is a necessity to have applications compatible with the system for the invention to have any 
type of utility, and thus the requirement of compatible applications is integral. 

As per claim 36, Spencer-Kelly teaches the method of claim 8, but does not specifically 
teach the use of application software roles as software roles. It would have been obvious to one 
of ordinary skill in the art to include this limitation, since application software roles are an 
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important part of software roles. The individual applications govern the characteristics of the 
software roles, so their inclusion as software roles is obvious. 

As per claim 37, Spencer-Kelly teaches the method of claim 36 on the basis of 
obviousness, wherein the application software roles define a group of services (column 3, lines 
57-61; where the SCOs administer the application software which have varying roles. These 
varying roles correspond to a variety or services.). 

As per claim 38, Spencer-Kelly teaches the method of claim 9, but does not specifically 
teach the use of application roles compatibility requirements as software roles compatibility 
requirements. It would have been obvious to one of ordinary skill in the art to include this 
limitation. The relationship between application roles and software roles is discussed in the 
discussion of claim 36. For the invention to have any utility, compatibility requirements of 
software roles and application roles must match, since applications are part of the overall 
software. It is thus obvious and necessary to include application roles compatibility 
requirements in software roles compatibility requirements. 

As per claim 39, Spencer-Kelly teaches the method of claim 38 on the basis of 
obviousness, wherein the application roles compatibility requirements define a group of services 
(column 3, lines 57-61; where the SCOs administer the application software, each with certain 
compatibility requirements. These applications correspond to various services. For the 
invention to function, the compatibility requirements must be met, since the applications will 
govern the use of the group of services, which thus defines the group.). 

As per claim 40, Spencer-Kelly teaches the method of claim 6, but does not specifically 
teach the characteristic of software packaging parameters relating to a variety of network service 
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tiers. It would have been obvious to one of ordinary skill in the art at the time of the invention to 
include this limitation, as the various ISPs (or network service tiers) would ultimately be the 
entities providing the provisioning services (column 2, lines 60-64). These services would come 
in the form of software packages. Thus the software parameters must be governed by the 
specific varieties of network service tiers. 

As per claim 41, Spencer-Kelly teaches the method of claim 7, but does not specifically 
teach the compatibility requirements being governed by network service tiers. It would have 
been obvious to one of ordinary skill in the art at the time of the invention to include this 
limitation, as the various ISPs (or network service tiers) would ultimately be the entities 
providing the provisioning services (column 2, lines 60-64). Thus, for the invention to function, 
the network service tiers must be compatible with the rest of the system. Internet services must 
have compatibility requirements since they ultimately govern the provisioning process. 

As per claim 42, Spencer-Kelly teaches the method of claim 6, but does not specifically 
teach the use of configuration parameters to define software packaging parameters. It would 
have been obvious to one of ordinary skill in the art at the time of the invention to include this 
limitation, as it is well known in the art. Software packaging parameters are specificities of 
configuration parameters and generally represent a subset of configuration parameters. It would 
thus be obvious to group them under the category of configuration parameters. 

As per claims 43-47, Spencer-Kelly teaches the method of claim 42 on the basis of 
obviousness. Claims 43-47 are rejected on the same basis of obviousness of claim 42, as all of 
the components are well known and obvious subsets of configuration parameters, and it would 
have been obvious to one of ordinary skill in the art to include these limitations. The motivation 
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for doing so is because the addition of these components allows for the use of various 
parameters, thus allowing for system compatibility, efficiency, and utility. 

As per claim 48, Spencer-Kelly teaches the method of claim 47 on the basis of 
obviousness, but does not specifically teach the use of device role configuration parameters as 
role configuration parameters. It would have been obvious to one of ordinary skill in the art to 
include this limitation, as it is well known. The motivation for doing so lies in the fact that the 
device characteristics are an integral part of the invention, and it is thus necessary for device role 
parameters to exist as role configuration parameters, as in the example of compatibility, the 
invention would not function if the device configuration is incompatible. As a result, there must 
be parameters for the device configuration in place to account for this. 

As per claim 49, Spencer-Kelly teaches the method of claim 48 on the basis of 
obviousness, wherein the device role configuration parameters comprise device role history 
configuration parameters (Spencer: column 9, lines 9-11, 56-61; where the rollback process 
depends on a configuration history. This history is part of the device role configuration 
parameters, since it is possible in certain situations that this configuration will be used.). 

As per claim 50, Spencer-Kelly teaches the method of claim 7, but does not specifically 
teach the use of configuration compatibility requirements as compatibility requirements. It 
would have been obvious to one of ordinary skill in the art to include this limitation, as it is well 
known in the art. The motivation for doing so lies in the fact that configuration compatibility 
requirements must match other compatibility requirements for the invention to function properly. 
Without criteria for proper configuration, there would be no consistency in configuration 
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compatibility, giving rise to incompatible configurations being loaded. This would lead to the 
invention's dysfunction and would thus defeat its purpose. 

As per claims 51-55, Spencer-Kelly teaches the method of claim 50 on the basis of 
obviousness. Claims 51-55 are rejected on the same basis of obviousness of claim 50, as all of 
the components are well known and obvious subsets of configuration compatibility parameters, 
and it would have been obvious to one of ordinary skill in the art to include these limitations. 
The motivation for doing so is because the addition of these components allows for the use of 
various compatibility parameters, thus allowing for system compatibility, efficiency, and utility, 
by allowing only those configurations that will function with the system. 

As per claim 56, Spencer-Kelly teaches the method of claim 55 on the basis of 
obviousness, but does not specifically teach the use of device role configuration compatibility 
requirements as role configuration compatibility requirements. It would have been obvious to 
one of ordinary skill in the art to include the device role configuration as a configuration 
compatibility requirement. The motivation for doing so lies in the fact that the device role is an 
integral part in the system as a whole, and thus must be consistent with the other compatibility 
requirements for the invention to function. Criteria of the device's function must be met for the 
invention to function, and thus a device role configuration compatibility requirement is 
necessary. 

As per claim 57, Spencer-Kelly teaches the method of claim 56 on the basis of 
obviousness, wherein the device role configuration compatibility requirements comprise device 
role history configuration compatibility requirements (Spencer: column 9, lines 9-11, 56-61; 
where the rollback process depends on a configuration history. This history is part of the device 
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role configuration parameters, since it is possible in certain situations that this configuration will 
be used. It is therefore implied that old device role configuration compatibility requirements are 
depended upon for any rollback process to be possible). 

As per claim 58, Spencer-Kelly teaches the method of claim 1, wherein the step of 
executing the at least one command is limited to entities having an approved access level to 
execute the at least one command (Spencer: column 2, lines 4-6). 

As per claim 59, Spencer-Kelly teaches the method of claim 58, wherein the access to 
execute the at least one command is defined in an access control list (Spencer: column 3, lines 
43-50; where the denial of certain users to access back-end servers implies the use of an access 
control list). 

As per claim 60, Spencer-Kelly teaches the method of claim 58 on the basis of 
obviousness, but does not specifically teach the definition of the access control list by domain 
name server. It would have been obvious to one of ordinary skill in the art to include this 
limitation, as it is well known in the art. The motivation for doing so lies in the fact that access 
to a server is initialized by the domain name server address. If an unauthorized DNS is 
attempting to access the provisioning system, the existence of safeguard, in the form of an 
authorization list to prevent this, is well known in the art. 

As per claim 61, Spencer-Kelly teaches the method of claim 58, wherein the entity 
executing the at least one command comprises an agent (Spencer: column 3, lines 43-54; where 
the SCO is the agent, and its access level is approved by the master object). 

As per claim 62, Spencer-Kelly teaches the method of claim 61, but does not specifically 
teach the limiting of access to the agent by the domain name server address of the network 
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device. It would have been obvious to one of ordinary skill in the art to include this limitation, 
as it is well known in the art. The motivation for doing so lies in the fact that access to a server 
is initialized by the domain name server address. If an unauthorized DNS is attempting to access 
the provisioning system, the disallowance of this act, based on the DNS address, is well known 
in the art. 

As per claim 63, Spencer-Kelly teaches the method of claim 9, but does not specifically 
teach the relation of a network device's IP address to the software roles compatibility 
requirements. It would have been obvious to one of ordinary skill in the art to include this 
limitation, as it is well known in the art. The motivation for doing so lies in the fact that an IP 
address of a network must be compatible for proper provisioning to take place. Therefore, there 
must exist criteria to govern whether an IP address is compatible. 

As per claim 64, Spencer-Kelly teaches the method of claim 9, but does not specifically 
teach the use of IP address compatibility requirements as a component of software roles 
compatibility requirements. It would have been obvious to one of ordinary skill in the art to 
include this limitation, as it is well known in the art. The motivation for doing so lies in the fact 
that a compatible IP address must exist for the invention to function. Therefore, it is necessary to 
include this criterion in the software's compatibility requirements, as the IP address 
compatibility is an integral part of the software's compatibility. The inclusion of the limitation 
gives rise to the proper function of the invention and is thus obvious. 

As per claim 65, Spencer-Kelly teaches the method of claim 1, and identifies 
configuration parameters to facilitate a rollback procedure (Spencer: column 9, lines 16-62), but 
does not specifically teach the specific identification of a VLAN associated with the network 
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device. In view of the necessity of monitoring the configuration of the network components in 
preparation for a rollback, it is obvious to one of ordinary skill in the art at the time of the 
invention to specifically include the identification of a VLAN. Doing so would add a 
characteristic to monitor during a rollback, and therefore the rollback can be performed in a more 
specific manner, pertaining solely to the VLAN in question. This teaching would allow for more 
efficiency into the invention of Spencer-Kelly and therefore would have been obvious to one of 
ordinary skill in the art at the time of the invention. 



Response to Arguments 



Applicant's arguments filed on August 1, 2008 have fully been considered, but are not 
persuasive. 

a. Applicant asserts that "the data store of Spencer merely provides information entered 
by a user about a device on which a command is to be executed," and therefore Spencer does not 
teach the limitation. Examiner respectfully disagrees, as the user-entered information is 
irrelevant. As taught in column 8, lines 24-57, Spencer teaches the "reading of parameters (the 
services to be configured, for example) related to a network device (the computer on which the 
service will be configured, for example) on which at least one received command (the request 
from the computer, for example) is to be executed (where the configuration is executed, for 
example). 

b. With respect to the rollback process, it takes place if it is determined that there is some 
installation error (column 9, lines 16-62). That is, a determination takes place whether a 
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command can properly be executed. If it cannot, the command is rolled back. Obviously, this 
installation and rollback process is based on the parameters read, that is, what the user requested 
be installed. If the requested service may be installed without incident, the system proceeds, and 
if it cannot, it is rolled back. Therefore, any determination of whether the service installations 
are properly executed is based on what the user requested (that is, the parameters read). As such, 
this limitation is fully taught by Spencer-Kelly. 

c. As Spencer teaches that parameters related to a network device are read, Kelly is 
relied upon for its concept of a database from which the parameters originate. This concept is 
common in the art. 

d. Claims 4, 10, 11, 16-57, 60, and 62-65 all teach common concepts in the art, and 
constitute well known design choices to include. As such, this inclusion would have been 
obvious to one of ordinary skill in the art. 

e. As per claim 6, the SCOs may be constituted by software. Since they are bundled 
together to form a service, they also constitute software packages. 

f. The SCOs execute the commands requested by the user, and if the user does not have 
an approved access level, the SCO cannot execute the commands. In that case, the SCO does not 
have an approved access level because of the user, and thus cannot execute the requested 
command. 



Conclusion 
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THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1 .136(a) will be calculated from the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than SIX MONTHS from the mailing 
date of this final action. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Tanim Hossain whose telephone number is (571)272-3881. The 
examiner can normally be reached on 8:30 am - 5 pm. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Jason Cardone can be reached on 571/272-3933. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 
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Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would 
like assistance from a USPTO Customer Service Representative or access to the automated 
information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 



Tanim Hossain 
Patent Examiner 
Art Unit 2145 



/Jason D Car done/ 
Supervisory Patent Examiner, Art Unit 2145 



